|
 |
On Thu, 28 Jan 1999 10:45:10 -0600, Bob Jamison <rja### [at] lincom-asg com> wrote:
>One thing I would like to add to any Wish List for
>new PovRay additions would be the ability of the
>parser to refer to resources by URL, in addition to
>file names. This would enormously simplify the problem
>of transferring resources for distributed raytracing.
>For example, if povray could have a command-line
>switch like:
>
>+Ihttp://someserver/somfile.pov
>
>and the parser could handle:
>
>#include "http://server/someotherfile.pov"
>
>or
>
>gif "http://imageserver/image.gif"
>
>
>...then a client application would never have to explicitly
>copy any data at all.
Neat idea, but I have questions. First, how would it
handle it if you did your first example above, and
somfile.pov #included a local .inc file? Would it
implicitly put http://someserver/ at the beginning of
the include path while processing remote files, or
would all #includes have to be explicit? Also, what
happens when someotherfile.inc defines a macro? At
present, every invocation of a macro results in the
file in which it is defined being reopened, fseek'd
to just after the #macro, and the macro reparsed with
the new symbol table. I think POV needs to make
temporary local copies of the required include files,
or at least the macro definitions, in this case.
Finally, the way #while is handled might be problematic,
as the #end causes it to seek back to the #while and
reparse until the #while ends up false. I'm pretty
sure http doesn't allow for random access like this.
Why is this even necessary? Are network file systems
like NFS or SMB too cumbersome? If you're going to
have to run an HTTP server on the master machine
anyway, why not run a more lightweight custom protocol
better suited to providing the needed information? You
might even consider a protocol that can just send the
entire preparsed frame and global settings to each client
rather than duplicating the parsing effort.
Post a reply to this message
|
|
